Transmitting data through commuincation switch

ABSTRACT

Methods, systems, and apparatuses related to a communication switch are disclosed herein. In some embodiments, the communication switch may be configured to transmit TDM, ATM and/or packet data from an ingress service processor, through a plurality of switch elements, to an egress service processor. Other embodiments may be described and claimed.

RELATED APPLICATIONS

This application claims priority to U.S. patent application Ser. No.10/155,517, filed May 24, 2002, which is a continuation-in-part of U.S.Pat. No. 6,631,130, issued Oct. 7, 2003, the specifications of which arehereby incorporated in their entirety.

FIELD

Disclosed embodiments relate to telecommunications networks and, moreparticularly, to transmitting data through telecommunication switches insaid networks.

BACKGROUND

One of the earliest techniques for employing broadbandtelecommunications networks was called time division multiplexing (TDM).The basic operation of TDM is simple to understand. A high frequencysignal is divided into multiple time slots within which multiple lowerfrequency signals can be carried from one point to another. The actualimplementation of TDM is quite complex, however, requiring sophisticatedframing techniques and buffers in order to accurately multiplex anddemultiplex signals. The North American standard for TDM (known as T1 orDS1) utilizes twenty-four interleaved channels together having a rate of1.544 Mbits/sec. The European standard for TDM is known as E-1 andutilizes thirty interleaved channels having a rate of 2.048 Mbits/sec. Ahierarchy of multiplexing is based on multiples of the T1 or E-1 signal,one of the most common being T3 or DS3. A T3 signal has 672 channels,the equivalent of twenty-eight T1 signals. TDM was originally designedfor voice channels. Today, however, it is used for both voice and data.

An early approach to broadband data communication was called packetswitching. One of the differences between packet switching and TDM isthat packet switching includes methods for error correction andretransmission of packets which become lost or damaged in transit.Another difference is that, unlike the channels in TDM, packets are notnecessarily fixed in length. Further, packets are directed to theirdestination based on addressing information contained within the packet.In contrast, TDM channels are directed to their destination based ontheir location in the fixed frame. Today, a widely used packet switchingprotocol is known as IP (Internet Protocol).

More recently, broadband technologies known as ATM and SONET have beendeveloped. The ATM network is based on fixed length packets (cells) of53-bytes each (48-bytes payload with 5-bytes overhead). One of thecharacteristics of the ATM network is that users contract for a qualityof service (QOS) level. Thus, ATM cells are assigned differentpriorities based on QOS. For example, constant bit rate (CBR) service isthe highest priority service and is substantially equivalent to aprovisioned TDM connection. Variable bit rate (VBR) service is anintermediate priority service which permits the loss of cells duringperiods of congestion. Unspecified bit rate (UBR) service is the lowestpriority and is used for data transmission which can tolerate highlatency such as e-mail transmissions.

The SONET network is based on a frame of 810-bytes within which a783-byte synchronous payload envelope (SPE) floats. The payload envelopefloats because of timing differences throughout the network. The exactlocation of the payload is determined through a relatively complexsystem of stuffs/destuffs and pointers. In North America, the basicSONET signal is referred to as STS-1 (or OC-1). The SONET networkincludes a hierarchy of SONET signals wherein up to 768 STS-1 signalsare multiplexed together providing the capacity of 21,504 T1 signals(768 T3 signals). STS-1 signals have a frame rate of 51.84 Mbit/sec,with 8,000 frames per second, and 125 microseconds per frame. In Europe,the base (STM-1) rate is 155.520 Mbit/sec, equivalent to the NorthAmerican STS-3 rate (3*51.84=155.520), and the payload portion isreferred to as the virtual container (VC). To facilitate the transportof lower-rate digital signals, the SONET standard uses sub-STS payloadmappings, referred to as Virtual Tributary (VT) structures. (The ITUcalls these Tributary Units or TUs.) Four virtual tributary sizes aredefined: VT-1.5, VT-2, VT-3 and VT-6. VT-1.5 has a data transmissionrate of 1.728 Mbit/s and accommodates a T1 signal with overhead. VT-2has a data transmission rate of 2.304 Mbit/s and accommodates an E1signal with overhead. VT-3 has a data transmission rate of 3.456 Mbit/sand accommodates a T2 signal with overhead. VT-6 has a data transmissionrate of 6.912 Mbit/s and accommodates a DS2 signal with overhead.

Each of the above described broadband technologies can be categorized asTDM, ATM, or Packet technologies, with SONET being a complex form ofTDM. From the foregoing, it will be appreciated that TDM, ATM and Packeteach desire their own unique transmission characteristics. Consequently,different kinds of switches are used to route these different kinds ofsignals. In particular, TDM desires careful time synchronization; ATMdesires careful attention to the priority of cells and QOS; and packet(e.g. IP) desires the ability to deal with variable length packets. Forthese reasons, switching technologies for TDM, ATM, and variable lengthpacket switching have evolved in different ways. Service providers andnetwork designers have thus been forced to deal with these technologiesseparately, often providing overlapping networks with different sets ofequipment which can only be used within a single network.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified schematic diagram of a port processor accordingto some embodiments;

FIG. 2 is a simplified schematic diagram of a switch element accordingto some embodiments;

FIG. 3 is a schematic diagram illustrating the data frame structure ofsome embodiments;

FIG. 3 a is a schematic diagram illustrating the presently preferredformat of a PDU according to some embodiments;

FIG. 3 b is a schematic diagram illustrating the row structure includingrequest elements to a first stage of the switch;

FIG. 3 c is a schematic diagram illustrating the row structure includingrequest elements to a second stage of the switch;

FIG. 4 is a schematic illustration of a three stage 48×48 switchaccording to some embodiments; and

FIG. 5 is a schematic illustration of a 48×48 folded Clos architectureswitch according to some embodiments.

BRIEF DESCRIPTION OF THE APPENDIX

Appendix A is an engineering specification (Revision 0.3) for a portprocessor according to some embodiments; and

Appendix B is an engineering specification (Revision 0.3) for a switchelement according to some embodiments.

DETAILED DESCRIPTION

The apparatus of some embodiments generally includes a port processorand a switch element. FIG. 1 illustrates some features of the portprocessor 10, and FIG. 2 illustrates some features of the switch element100. Referring now to FIG. 1, the port processor 10 includes a SONETinterface and a UTOPIA interface. On the ingress (RX) side, the SONETinterface includes a serial to parallel converter 12, a SONET framer andtransport overhead (TOH) extractor 14, a high order pointer processor16, and a path overhead (POH) extractor 18. For ATM and IP packetstransported in an SPE, the ingress side of the SONET interface includesforty-eight HDLC framers 20 (for IP), forty-eight cell delineators 22(for ATM), and forty-eight 64-byte FIFOs 24 (for both ATM and IP). ForTDM signals transported in an SPE, the ingress side of the SONETinterface includes a demultiplexer and low order pointer processor 26.On the egress (TX) side, the SONET interface includes, for TDM signals,a multiplexer and low order pointer generator 28. For ATM and IP packetstransported in an SPE, the egress side of the SONET interface includesforty-eight 64-byte FIFOs 30, forty-eight HDLC frame generators 32, andforty-eight cell mappers 34. The egress side of the SONET interface alsoincludes a POH generator 36, a high order pointer generator 38, a SONETframer and TOH generator 40, and a parallel to serial interface 42. Onthe ingress side, the UTOPIA interface includes a UTOPIA input 44 forATM and Packets and one 4.times.64-byte FIFO 46. On the egress side, theUTOPIA interface includes ninety-six 4.times.64-byte FIFOs 48 and aUTOPIA output 50.

The ingress portion of the port processor 10 also includes a switchmapper 52, a parallel to serial switch fabric interface 54, and arequest arbitrator 56. The egress portion of the port processor alsoincludes a serial to parallel switch fabric interface 58, a switchdemapper 60, and a grant generator 62.

For processing ATM and packet traffic, the port processor 10 utilizes,at the ingress portion, a descriptor constructor 64, an IPF and ATMlookup processor 66, an IP classification processor 68, an RED/Policingprocessor 70, all of which may be located off-chip. These units processATM cells and packets before handing them to a (receive) data linkmanager 72. At the egress portion of the port processor, a (transmit)data link manager 74 and a transmit scheduler and shaper 76 areprovided. Both of these units may be located off-chip. The portprocessor is also provided with a host interface 78 and a weighted roundrobin scheduler 80.

The purpose of the port processor at ingress to the switch is to unpackTDM, Packet, and ATM data and frame it according to the data framedescribed below with respect to FIG. 3. The port processor also buffersTDM and packet data while making arbitration requests for link bandwidththrough the switch element and grants arbitration requests receivedthrough the switch as described in more detail below. In order tomaintain timing for TDM traffic, predetermined bytes, e.g., the V1-V4bytes in the SONET frame, may be stripped off and the VC bytes arebuffered at the ingress to the switch. In rows having both PDU and TDMtraffic, it may be desirable for the PDUs to be configured early and theTDM slots to be configured late in the row. At the egress of the switch,the port processor reassembles TDM, Packet, and ATM data. The V1-V4bytes are regenerated at the egress from the switch.

Though not shown in FIG. 1, the port processor 10 includes dual switchelement interfaces which permit it to be coupled to two switch elementsor to two ports of one switch element. When both interfaces are used,the “standby” link carries only frame information until a failure in themain link occurs and then data is sent via the standby link. Thisprovides for redundancy in the switch so that connections are maintainedeven if a portion of the switch fails.

Turning now to FIG. 2, a switch element 100 according to someembodiments includes twelve “datapath and link bandwidth arbitrationmodules” 102 (shown only once in FIG. 2 for clarity). Each module 102provides one link input 104 and one link output 106 through the switchelement 100. Those skilled in the art will appreciate that data enteringany link input can, depending on routing information, exit through anylink output. According to some embodiments, each module 102 provides twoforward datapaths 108, 110, 112, 114 and one return “grant” path 116,118. The three paths are collectively referred to as constituting asingle channel. The reason why two datapaths are provided is to increasethe bandwidth of each channel. The two datapaths are interleaved toprovide a single “logical” serial datastream which exceeds (doubles) thebandwidth of a single physical datastream. Data is routed from an inputlink 104 to an output link 106 via an input link bus 120 and an outputlink bus 122. Return path grants are routed from an output link 106 toan input link 104 via a grant bus 124.

The forward datapaths of each “datapath and link bandwidth arbitrationmodule” 102 include a data stream deserializer 126, a data streamdemapper 128, a row buffer mapper 130, a row buffer 132, a requestarbitration module 134, a data stream mapper 136, and a data streamserializer 138. The return grant path for each module 102 includes agrant stream deserializer 140, a grant stream demapper 142, a grantarbitration module 144, a grant stream mapper 146, and a grant streamserializer 148.

The switch element 100 also includes the following modules which areinstantiated only once and which support the functions of the twelve“datapath and link bandwidth arbitration modules” 102: a linksynchronization and timing control 150, a request parser 152, a grantparser 154, and a link RISC processor 156. The switch element 100 alsoincludes the following modules which are instantiated only once andwhich support the other modules, but which are not directly involved in“switching”: a configuration RISC processor 158, a system control module160, a test pattern generator and analyzer 162, a test interface busmultiplexer 164, a unilink PLL 166, a core PLL 168, and a JTAG interface170.

A typical switch according to some embodiments includes multiple portprocessors 10 and multiple switch elements 100. For example, as shown inFIG. 4, forty-eight “input” port processors are coupled to twelve,“first stage” switch elements, four to each. Each of the first stageswitch elements may be coupled to eight second stage switch elements.Each of the second stage switch elements may be coupled to twelve thirdstage switch elements. Four “output” port processors may be coupled toeach of the third stage switch elements. From the foregoing, thoseskilled in the art will appreciate that the port processors and theswitch elements of invention can be arranged in a folded Closarchitecture as shown in FIG. 5 where a single switch element acts asboth first stage and third stage.

Before describing in detail the functions of the port processor 10 andthe switch element 100, it should be appreciated that some embodimentsutilize a unique framing technique which is well adapted to carrycombinations of TDM, ATM, and Packet data in the same frame. Turning nowto FIG. 3, according to some embodiments, a data frame of nine rows by1700 slots is used to transport ATM, TDM, and Packet data from a portprocessor through one or more switch elements to a port processor. Eachframe is transmitted in 125 microseconds, each row in 13.89microseconds. Each slot includes a four-bit tag plus a four-byte payload(i.e., thirty-six bits). The slot bandwidth ( 1/1700 of the total frame)is 2.592 Mbps which is large enough to carry an E-1 signal withoverhead. The four-bit tag is a cross connect pointer which may be setup when a TDM connection is provisioned. The last twenty slots of theframe are reserved for link overhead (LOH). Thus, the frame is capableof carrying the equivalent of 1,680 E-1 TDM signals. The link overhead(LOH) in the last twenty slots of the frame is analogous in function tothe line and section overhead in a SONET frame.

The contents of the LOH slots may be inserted by the switch mapper (52in FIG. 1). There are four types of data which may be inserted in theLOH slots. A 36-bit framing pattern may be inserted into one of thetwenty slots. The framing pattern may be common to all output links andconfigurable via a software programmable register. A 32-bit status fieldmay be inserted into another slot. The status field may be unique foreach output link and may be configurable via a software programmableregister. A 32-bit switch and link identifier may be inserted intoanother slot. The switch and link identifier includes a four bit linknumber, a twenty-four bit switch element ID, and a four bit stagenumber. A 32-bit stuff pattern may be inserted into slots not used byframing, status, or ID. The stuff pattern is common to all output linksand may be configurable via a software programmable register.

For ATM and packet data, a PDU (protocol data unit) of sixteen slots maybe defined for a sixty-four-byte payload (large enough to accommodate anATM cell with overhead). The format of the PDU is illustrated in FIG. 3a. A maximum of ninety-six PDUs per row may be permitted (it being notedthat the maximum number of ATM cells in a SONET OC-48 row isseventy-five). The sixteen four-bit tags (bit positions 32-35 in eachslot) are not needed for PDU routing so they may be used as parity bitsto protect the ATM or IP payload. Of the sixty-four-byte payload, twelvebytes (96 bits) may be used by the switch for internal routing (slots0-2, bit positions 0-31). This leaves fifty-two bytes (slots 3-15) foractual payload which is sufficient to carry an ATM cell (without theone-byte HEC) and sufficient for larger packets after fragmentation. ThePDUs may be self-routed through the switch with a twenty-eight-bitrouting tag (slot 0, bit positions 0-27) which allows routing-throughseven stages using four bits per stage. The remaining sixty-eight bitsof the PDU may be used for various other addressing information.

As shown in FIG. 3 a, the PDU bits at slot 0, bits 30-31 may be used toidentify whether the PDU is idle (00), an ATM cell. (01), an IP packet(10), or a control message (11). The two bits at slot 1, bit positions30-31 may be used to indicate the internal protocol version of the chipwhich produced the PDU. For Packets and control messages, the “validbytes” field (slot 1, bits 24-29) may be used to indicate how manypayload bytes are carried by the PDU when the FragID field indicatesthat the PDU is the last fragment of a fragmented packet. The VOQIDfield (slot 1, bit positions 19-23) identifies the class of service forthe PDU. The class of service can be a value from 0 to 31, where 0 isthe highest priority and 31 is the lowest. The FragID at slot 1, bits17-18 indicates whether this PDU is a complete packet (11), a firstfragment (01), a middle fragment (00), or a last fragment (10). The Abit at slot 1, bit position 16 is set if reassembly for this packet isbeing aborted, e.g. because of early packet (or partial packet) discardoperations. When this bit is set, fragments of the packet received untilthis point are discarded by the output port processor. The fieldslabelled FFS are reserved for future use. The Seq# field at slot 1, bits0-3 is a modular counter which counts packet fragments. The DestFlowIdfield at slot 2, bits 0-16 identifies the “flow” in the destination portprocessor to which this PDU belongs. A “flow” is an active dataconnection. There are 128K flows per port processor.

As mentioned above, since ATM and Packet traffic are typically notprovisioned, bandwidth may be arbitrated among ATM and Packetconnections as traffic enters the system. Moreover, since TDM trafficshares the same frame as ATM and Packet traffic, bandwidth may bearbitrated while maintaining TDM timing. According to some embodiments,bandwidth is arbitrated by a system of requests and grants which isimplemented for each PDU in each row of the frame. The request elements,which are generated by the port processors include “hop-by-hop” internalswitch routing tags, switch element stage, and priority information.According to some embodiments two request elements are sent in a threecontiguous slot bundle and at least eight slots of non-request elementtraffic must be present between request element bundles. The timeseparation between request element bundles may be used by thearbitration logic in the switch elements and the port processors toprocess the request elements. The request element format is shown insection 7.1.5 of Appendix B.

FIG. 3 b illustrates one example of how the row slots may be allocatedfor carrying PDUs and request elements. As shown, the maximum PDUcapacity for a row is ninety-six. A block of sixteen slots which iscapable of carrying a single PDU is referred to as a “group”. For eachgroup in the row, 1.5 slots of bandwidth may be used for carrying aforty-eight-bit request element (RE). FIG. 3 b illustrates how two REsare inserted into three slots within each of the first twenty-fourgroups. All the REs may be carried within the row as early as possiblein order to allow the RES to ripple through the multistage switch fabricas soon as possible after the start of a row. Section 7 of Appendix Bexplains in detail how this affects the arbitration process.

The structure shown in FIG. 3 b may be the desired format (for the firstlink) given system requirements and implementation constraints of agiven embodiment. It places the REs early in the row but spaces them outenough to allow for arbitration. According to the present embodiment,the row structure is somewhat different depending on for which link ofthe switch it is configured. FIG. 3 b represents the row structurebetween the port processor and a switch element of the first switchfabric stage. The first block of two REs occupy the first three slots ofthe row. The present implementation of the arbitration logic whichprocesses REs requires at least twelve slot times of latency betweeneach three-slot block of REs on the input link. Also, there may be somelatency from when the first REs of the row are received by a switchelement to when the REs are inserted into the output link of the switchelement. This latency is used by the arbitration logic for mappingincoming REs into the RE buffers. Thus, the row structure for the linkbetween the first stage and the second stage may have the first group ofREs starting at slot time 32. This is illustrated in FIG. 3 c, whichshows the same structure as FIG. 3 b offset by thirty-two slot times.

According to some embodiments, TDM traffic may be switched through theswitch elements with a finest granularity of one slot per row. The TDMtraffic may be switched through the same path for a given slot for everyrow. The switch elements may not allow different switch paths for thesame TDM data slot for different rows within the frame. This means thatthe switch does not care about what the current row number is (within aframe). The only time row numbering matters is when interpreting thecontents of the Link Overhead slots.

With a finest granularity of one slot per row, the switch elements canswitch TDM traffic with a minimum of 2.52 Mbps of switching bandwidth.Since a slot can carry the equivalent of four columns of traffic from aSONET SPE, it can be said that the switch elements switch TDM trafficwith a granularity of a VT1.5 or VT2 channel. Although a VT1.5 channelmay only occupies three columns in the SONET SPE, it will still bemapped to the slot format which is capable of holding four SPE columns.As mentioned above, the format of the contents of the thirty-six-bitslot carrying TDM traffic is a four-bit tag and a thirty-two bits ofpayload. The tag field definitions are shown in Table 1 below.

TABLE 1 0000 Idle 0001 reserved 1010 reserved 1011 Data present 1100 V5byte in bits 31-24 1101 V5 byte in bits 23-16 1110 V5 byte in bits 15-81111 V5 byte in bits 7-0

The switch elements know whether or not a slot contains TDM data viapreconfigured connection tables. These tables may be implemented as anInput Cross Connect RAM for each input link. The input slot number isthe address into the RAM, while the data output of the RAM contains thedestination output link and slot number. The connection table can bechanged by a centralized system controller which can send controlmessages, to the switch elements via either of two paths: (1) a hostinterface port or (2) in-band control messages which are sent via thelink data channel. Since TDM connections will be changed infrequently,this relatively slow control message approach to update the connectiontables is acceptable. It is the responsibility of an external softwaremodule to determine and configure the connection tables within theswitch elements such that no TDM data will be lost.

Returning now to FIG. 1, the receive side SONET interface of the portprocessor 10 includes the deserializer 12 and framer 14. This interfacemay be configured as one OC-48, 16-bits wide at 155 MHz, four OC-12s,serially at 622 MHz, or four OC-3s, serially at 155 MHz. When configuredas one OC-48, the deserializer 12 is not used. When configured as fourOC-12s or one OC-48, the deserializer 12 converts the serial data streamto a sixteen-bit wide parallel stream. The deserializer 12 includescircuitry to divide the input serial clocks by sixteen. The inputs tothe deserializer include a one-bit serial data input, a one-bit 622 MHzclock and a one-bit 155 MHz clock. The outputs include a sixteen-bitparallel data output, a one-bit 38.87 MHz clock and a 9.72 MHz clock.The SONET interfaces are described in more detail in sections 3.2 and3.3 of Appendix A.

Parallel data is sent to the SONET framer and transport overhead (TOH)block 14. All incoming signals may be framed according to the BELLCOREGR-253 standard which is incorporated herein by reference. The byteboundary and the frame boundary are found by scanning a series ofsixteen bit words for the F628 pattern. The framer frames on the patternF6F6F62828288. Independent SONET SPEs within the STS-N frame aredemultiplexed by the framer 14. There is a maximum of four independentline interfaces, therefore the framer 14 includes four independentframers. The inputs to the framer include a sixteen-bit parallel datainput, and a one-bit clock which will accept 155 MHz, 38.87 MHz, or 9.72MHz. The outputs of the framer include a sixteen-bit parallel dataoutput, a one-bit start of frame (SOF) indication, a six-bit SPE ID usedto indicate SONET SPE number. The SPEs are numbered 1 through 48 withrespect to the line side port configuration.

The block 14 also terminates the transport (section and line) overheadfor each independent SONET SPE. Since there are a maximum of forty-eightOC-1s on the line side, forty-eight transport overhead blocks areprovided unless blocks are time-shared. The inputs to the TOHtermination are the same as those discussed above with respect to theframer. The six-bit SPE ID enables data into this block. There may be noneed for an output data bus as the traffic is routed to this block andto the next block (Ptr Proc 16) on the same data bus. The data path mayonly flow into this block, not through it.

The pointer processor 16 uses the SONET pointer (H1, H2 and H3 bytes inthe TOH) to correctly locate the start of the payload data being carriedin the SONET envelope. The SONET pointer identifies the location of byte#1 of the path overhead. The pointer processor 16 is responsible foraccommodating pointer justifications that were inserted in order tojustify the frequency difference between the payload data and the SONETenvelope. Since there may be a maximum of forty-eight OC-1s, forty-eightpointer processor blocks are mated to the forty-eight transport overheadtermination blocks unless blocks are time-shared. The inputs to thepointer processor 16 are the same as those to the framer and TOHterminator 14. The outputs include a sixteen-bit parallel data output, aone-bit start of SPE indicator which coincides with word 1 of SPE 3, aone-bit SPE valid indicator which gaps out overhead and accommodatespointer movements, and a one-bit POH valid indicator which indicateswhen a path overhead byte is on the output bus.

The POH processor 18 processes the nine bytes of Path Overhead in eachof the forty-eight SONET SPES. Since there are a maximum of forty-eightSPEs, forty-eight path overhead processors are provided unlessprocessors are time-shared. The inputs to the path overhead processor 18include an eight-bit parallel data input, a four-bit SPE ID, the one-bitstart of SPE indicator, and the one-bit POH valid indicator. The outputsinclude a one-bit V1 indicator, J1 info, alarms, and path status.Further details about blocks 14, 16, and 18 are provided by the GR-253standard and documentation accompanying standard SONET mapper/demapperssuch as those available from Lucent or TranSwitch.

Once the frame boundaries of the incoming SONET/SDH signals are foundand the location of the SPEs has been identified either through pointerprocessing or through Telecom bus I/F control signals, and the PathOverhead is processed, the payload is extracted from the SPE. The SPEsmay be carrying TDM traffic, ATM cells or IP packets. The type oftraffic for each SPE may be configured through the microprocessorinterface 78. Each SPE can carry only one type of traffic. The data fromeach SPE is routed directly to the correct payload extractor.

SPEs containing packets and ATM cells may be sent to the HDLC framer 20and the cell delineation block 22, respectively. Each SPE may beconfigured to carry packet data (packet over SONET). The Port Processor10 supports packet over SONET for the following SONET (SDH) signals:STS-1 (VC-3), STS-3c (VC-4), STS-12c (VC-4-4c), and STS-48c (VC-4-16c).The datagrams may be encapsulated in PPP packets which are framed usingthe HDLC protocol. The HDLC frames are mapped byte wise into SONET SPEsand high order SDH VCs. The HDLC framer 20 performs HDLC framing andforwards the PPP packet to a FIFO buffer 24 where it awaits assemblyinto PDUs. The framer 20 has an input which includes a sixteen-bitparallel data input, a six-bit SPE ID, a one-bit SPE valid indicator,and a one-bit PYLD valid indicator. The output of the framer 20 includesa sixteen-bit data bus, a one-bit start of packet indicator, and aone-bit end of packet indicator. Further details about packet extractionfrom SONET are found in IETF (Internet Engineering Task Force) RFC 1619(1999) which is incorporated herein by reference.

The cell delineation block 22 is based on ITU-T G.804, “ATM Cell Mappinginto Plesiochronous Digital Hierarch (PDH)”, 1998, the completedisclosure of which is hereby incorporated herein by reference. The celldelineation block 22 has inputs that include a sixteen-bit parallel databus, a six-bit SPE ID, a one-bit SPE valid indicator, and a one-bit POHvalid indicator. The outputs include a sixteen-bit parallel data bus anda one-bit start of cell indicator. Cells are placed in a FIFO 24 whileawaiting assembly into PDUS. Further details regarding ATM extractionfrom SONET are found in ITU-T G.804.

The TDM data is routed to a TDM demultiplexer and low order pointerprocessor block 26 where the low order VTs and VCs are identified. If aparticular SPE is configured for TDM data, then the TDM mapping isdescribed using the host interface 78. Each SPE can carry a combinationof VC-11, VC-12, VC-2, VC-3 & VC-4. There are seven VT groups in asingle STS-1 payload, each VT group has twelve columns. Within one VTGroup all of the VTs must be the same. Different VT groups within thesame STS-1 SPE can carry different VT types, but within the group allVTs may be of the same type. The VCs and VTs are demultiplexed out ofthe SONET signal based on the configuration for each of the SPEs. Thereis no interpretation of the traffic required to locate the containersand tributaries as all of this information is found in the configurationtable (not shown) which is configured via the host interface 78. Framesare located inside of the VCs and the VTs through the H4 byte in thepath overhead of the SPE. Pointer processing is performed as indicatedby the V bytes in the VT superframe. The TDM demultiplexer and low orderpointer processor block 26 has inputs which include sixteen bits ofparallel data, a six-bits SPE ID, a one-bit start of SPE indicator, aone-bit SPE valid indicator, a one-bit V1 indicator, and one-bit POHvalid indicator. The TDM demultiplexer and low order pointer processorblock 26 provides the following outputs to the switch mapper 52: sixteenbits of parallel data, a one-bit VT/VC valid indicator, a six-bit SPEID, and a five-bit VT/VC Number (0-27). The TDM data is placed inreserved slots in the frame as mentioned above and described in moredetail below with reference to the switch mapper 52. Further detailsregarding TDM extraction are found in the GR-253 specification

IP packets and ATM cells from the UTOPIA interface 44 may be placed inFIFO 46. Packets and cells from the FIFOs 24 may be merged with thepackets and cells from the FIFO 46. The descriptor constructor 64determines whether the data is an ATM cell or an IP packet and generatesa corresponding interrupt to trigger the IPF/ATM look-up processor 66 toperform either IP routing look-up or ATM look-up. IP routing look-up isperformed by searching for the IP destination address for every packetand the IP source address for packets that need classification. ATMlook-up is performed by searching the VPI/VCI fields of the cells.Outputs of the IPF/ATM look-up processor 66 for both IP packets and ATMcells include a seventeen-bit flow; index, a five-bit QOS index, and anindicator showing whether the IP packet-needs classification. If the IPpacket needs classification, the packet is passed to the IPclassification processor 68 for classification; otherwise it is passedto the next stage of packet processing, the RED/policing processor 70.IP classification is described in detail in section 6.4 of Appendix A.The RED/Policing processor 70 performs random early detection andweighted random early detection for IP congestion control, performsleaky bucket policing for ATM traffic control, and performs early packetand partial packet discard for controlling ATM traffic which containspackets. The RED/Policing traffic control is described in detail insections 7.5 et seq. of Appendix A. Some embodiments of the portprocessor 10 includes a mode register (not shown) which can be placed ina bypass mode to globally turn off the IP/ATM forwarding. In bypassmode, an external device is used for IP/ATM forwarding, and the datadescriptors generated by the descriptor constructor 64 are routeddirectly to an output FIFO (not shown).

All of the data stored in the FIFOs 24 and 46 may be in fifty-two-byte“chunks”. If an IP packet is longer than fifty-two-bytes, it may besegmented into multiple fifty-two-byte chunks. The input data descriptorfor each chunk includes indications of whether the chunk is an ATM cellor a packet, whether it is the start of a packet or the end of a packet,packet length, and the source and destination port numbers. Afterprocessing by the IPF/ATM lookup processor 66 and the IP classificationprocessor 68, an output data descriptor is written to a FIFO (not shown)which is read by the RED/Policing processor 70.

Cells and packets which survive RED/policing are read by the receivedata link manager 72, which creates the PDUs described above withreference to FIG. 3 a. The receive data link manager, is described indetail in section 8 of Appendix A. According to some embodiments,processed cells and packets are stored in an external FIFO which is readwhenever it is not empty.

As shown in FIG. 1, the switch mapper 52 receives TDM traffic from theTDM demultiplexer and low order pointer processor 26 as well as PDUsfrom the data link manager 72. As mentioned above, the switch mapperalso receives request elements. The request elements are formed by thearbiter 56 as described in more detail below. It is the function of theswitch mapper (also referred to as the data mapper in Appendix A) toarrange TDM data, PDUS, and request elements in the frame describedabove with reference to FIGS. 3 and 3 a-c.

The switch mapper 52 includes a state machine (not shown) which isassociated with the ATM/IP PDUS. The data link manager 72 writes thePDU's using a sixty-four-bit interface to the external FIFO (not shown).The data may be transmitted from the external FIFO to the switch mapper52 in thirty-two-bit slots with four bits of parity. The state machineassociated with the external PDU FIFO monitors the status of the FIFOand maintains data integrity.

In section 9 of Appendix A, the data link manager 72, arbiter block 56,switch mapper 52, and weighted round robin scheduler 80, together withmemory and other support circuits (not shown in FIG. 1) are referred tocollectively as the “receive switch controller”. As described in detailabove, each incoming ATM cell and packet is processed by performing alookup based on the ATM VPI/VCI or on the IP source and destination.This lookup first verifies that the connection is active, and if active,it returns a seventeen-bit index. For ATM cells, the index points to aset of per VC parameters and to routing information. For packets, theindex points to a set of queuing parameters and to routing information.The seventeen-bit index supports a maximum of 128K simultaneous IP andATM flows through the port processor. The ATM cells are encapsulated ina cell container and stored in one of 128K queues in external memory.These 128K queues are managed by the data link manager 72. As mentionedabove, the IP packets are fragmented into fifty-two-byte blocks and eachof these blocks may be encapsulated in a cell container (PDU). Thesecell containers are also stored in one of the 128K queues in externalmemory by the data link manager. The 128K IP/ATM flows may be aggregatedinto one of thirty-two QOS queues for scheduling through the switch. Thedata link manager 72 also aggregates all the control headers desired fortransmission of cells through the switch into the QOS queues and insertsthese routing tags into one of thirty-one QOS routing tag FIFOS. One ofthe queues may be reserved for high priority traffic. Any cells arrivingin the high priority queue may be interrupt the scheduler 80 and may bescheduled to leave the high priority queue immediately.

The scheduler 80 may be responsible for scheduling cell containersthrough the switch. The scheduling algorithm used may be a weightedround robin, which operates on the QOS queues. Once cells have beenscheduled from these queues the control headers from these queues areforwarded to the arbiter 56 and are stored in a request control table(not shown). The request arbiter 56 forms request elements from thecontrol headers and forwards these requests to the switch data mapper 52for transmission through the switch. The grants received in response tothese requests may be deserialized by block 58, deframed and transferredback to the arbiter block 56 by the grant block 62. For grantedrequests, the cell containers may be dequeued from external memory bythe data link manager 72 and transferred to the switch mapper 52 fortransmission through the switch.

As mentioned above, the port processor 10 supports redundancy in orderto improve reliability. Two redundancy schemes are supported. In thefirst redundancy scheme, the switch controller supports redundantrouting tags and transparent route switch-over. In the second redundancyscheme, the port processor supports redundant data channels in bothinput and output directions. The redundant data channels connect to twoseparate switch fabrics. In the Appendices they are referred to as the Aand B data channels. Each control header contains two routing tags, andeach routing tag has a corresponding AB channel tag. This provides fortwo routes through the switch for data transmission. If both routingtags have the same channel tag, this allows for two alternate pathsthrough the same switch fabric. If both routing tags have differentchannel tags, this allows for a redundant switch fabric and any routefailing in one switch fabric will cause a switch-over to use theredundant switch fabric. An AB channel tag may be used to indicatewhether the data is to be routed using the A data channel or the B datachannel. If, after a programmable number of consecutive tries, no grantis received in response to request elements using the A channel routingtag, a bit may be set to switch over to the B channel routing tag.Further details of the redundancy feature are provided in sections10.2.3 and 9.2.3 of Appendix A.

As mentioned above, the arbiter 56 may be responsible for sendingrequests to the switch mapper 52 and processing the grants that arrivefrom the grant demapper 62. The arbiter dequeues requests from a routingtag FIFO, copies this information into a request control table, writesthe FLOWID into FLOWID RAM, resets a request trial counter that countsthe number of times a request has been tried, and resets the grant bit.Each request message has a unique request ID which is returned in thegrant message. The request ID is the index in the arbiter requestcontrol table into which the routing tag is copied. The routing tagalong with the request ID may be forwarded to a routing tag formatterblock, which formats the routing tag into a request message and insertsthe request into a request FIFO in the switch mapper 52.

The grant demapper in the grant block 62 stores the request ID and thegrant in a FIFO called the grant_reqid FIFO. In the arbiter_block 56,the request IDs are dequeued from A and B grant reqid FIFOSalternatively depending on whether the switchover bit is set. Therequest IDs dequeued from the FIFO are used to set a grant bit in thegrant register at the bit position indicated by the request ID, to indexthe FLOWID.RAM, and read the FLOWID associated with the request ID. ThisFLOWID is written into a deq-flowid FIFO for the appropriate channel,i.e., if the request ID is dequeued from the A reqid_fifo, the FLOWID iswritten into the A deq_flowid fifo. The data link manager 72 monitorsthe deqflowid_fifo and uses the FLOWID to dequeue data PDUs fromexternal memory and send them to the switch mapper 52 for transmissionin the next row time.

An end_of_grants signal is asserted by the grant demapper 62, when nomore grants can be received at the grant demapper. In most switchimplementations the end_of_grants signal is rarely, if ever, asserted.It is only in switches having many stages that the end_of_grants signalis more likely to be asserted. Once the end_of_grant signal has beenreceived the arbiter 56 begins the process of updating the requestcontrol table. If a grant has not been returned for a routing tag storedin the request control table, the request trial counter is incrementedand a new request is generated using the routing tag. If a routing tagin the request control table has been sent as a RE a (programmed)maximum number of times, the most significant fifteen bits of the FLOWIDare used to index into the redundancy control table and update the bitto indicate failure of the current path and to select the alternaterouting path. Further details regarding the arbiter block 56 areprovided at section 9.2.4 of Appendix A.

As described above, the TDM data, ATM/IP PDU's and the request messagesmay be combined into a single data stream for transmission through theswitch fabric. This combination may be performed by the switch mapper 52on the receive side of the port processor. On the transmit side of theport processor, a switch demapper 60 separates TDM data from ATM/IPPDUs. According to some embodiments, the demapper 60 may be providedwith external memory for a PDU FIFO. For ATM/IP data, the demapperwrites PDUs to the FIFO and interrupts the data link manager 74. Thedata link manager 74 reads the header information from the PDU FIFO, andextracts the FLOWID. Based on the FLOWID, the datalink manager 74retrieves a Linked List/Shaping/Scheduling data structure from externalmemory. The data link manager 74 writes the linked list pointers to thePDU FIFO, then initiates a DMA transfer to move the PDU to externalmemory. The data link manager updates the head, tail, and count fieldsin the Linked List/Shaping/Scheduling data structure and passes the datastructure to the Shaping/Scheduling processor 76 through aShaping/Scheduling FIFO. The Shaping/Scheduling processor 76 performsthe Shaping and Scheduling functions and updates the LinkedList/Shaping/Scheduling datastructure.

The data-flow from external memory to the SONET/UTOPIA Data FIFOs 30 and48 may be as follows. The data link manager 74 polls the PDU FIFO andSONET/UTOPIA FIFO status flags. If the PDU FIFO is not empty and theSONET/UTOPIA FIFO is not full for a particular output port, the datalink manager 74 retrieves the Link List/Shaping/Scheduling datastructure for the Flow ID read from the PDU FIFO. (Note that for an IPpacket flow, the data link manager will continue to retrieve PDUs fromthe Linked List until a PDU with an End of Packet indicator is found.)The data link manager then initiates a DMA transfer from external memoryto the SONET/UTOPIA FIFOs 30, 48. The data link manager 74 then updatesthe Link List/Shaping/Scheduling data structure and writes it back toexternal memory.

On the transmit side of the port processor 10, the grant framer,deframer, serializer and deserializer in the grant block 62, the switchdemapper 60, the transmit datalink manager 74, and the transmitscheduler and shaper 76 are referred to collectively as the transmit(TX) switch controller in Appendix A. The TX switch controller isresponsible for either accepting or rejecting requests that come intothe port processor for output transmission. To do this, the TX switchcontroller checks if the queue identified by the output port number ofthe request can accept a cell container. These one hundred twenty-eightqueues may be managed by the TX data link manager 74. According to someembodiments, these queues are stored in external memory. The schedulingof these cell containers may be performed by the TX scheduler 76. If thequeue can accept the cell container, the request is turned into a grantand inserted into a grant_fifo. The grant-framer and serializer 62 readsthis information and creates a grant message for transmission throughthe grant path.

The TX switch controller-monitors the status of the data queues for eachof the one hundred twenty-eight output ports using the following threerules. If the full_status bit for the requested output port is set,there is no buffer space in the queue for any data PDUs destined forthat output port and all requests to that output port may be denied. Ifthe full_status bit is not set and the nearly_full_status bit is set,there is some space in the queue for data PDUs destined for that outputport; however this space may be reserved for higher priority traffic. Inthis instance the QOS number is checked against a threshold (programmed)QOS number and if the QOS number is less than the threshold, the requestwill be accepted. If the nearly full_status bit is not set, all incomingrequests may be granted. If a request is accepted, the correspondingoutput port counter is incremented. This reserves space in the databuffer (30 or 48) for the arrival of the data PDU at that output port.The transmit data link manager 74 constantly monitors the one hundredtwenty-eight output port counters and sets/resets the one hundredtwenty-eight full and nearly full status bits.

The port processor 10 creates complete outgoing SONET signals. All ofthe transport and path overhead functions are supported. The SONETinterfaces can run in source timing mode or loop timing mode.

The high order pointer is adjusted by the high order pointer generator38 through positive and negative pointer justifications to accommodatetiming differences in the clocks used to generate the SONET frames andthe clock used to generate the SONET SPEs. At initialization, SPE FIFOsmay be allowed to fill to halfway before data is taken out. Thevariations around the center point are monitored to determine if therate of the SONET envelope is greater than or less than the rate of theSPE. If the rate of the SONET envelope is greater than the rate of theSPE, then the SPE FIFO will gradually approach a more empty state. Inthis case, positive pointer movements will be issued in order to givethe SPE an opportunity to send additional data. If the rate of the SONETenvelope is less than the rate of the SPE, then the SPE FIFO willgradually approach a more full state. In this case, negative pointermovements will be issued in order to give the SPE an opportunity tooutput an extra byte of data from the FIFO. The SONET framer and TOHgenerator 40 generate transport overhead according to the BELLCOREGR-253 standard.

The outgoing SONET frames may be generated from either the timingrecovered from the receive side SONET interface or from the sourcetiming of the Port Processor. Each signal is configured separately andthey can be configured differently. The frame orientation of theoutgoing SONET frames may be arbitrary. Each of the four signals can berunning off different timing so there is no need to try to synchronizethem together as they will constantly drift apart. There is no need toframe align the Tx ports to the Rx ports as this would result inrealigning the Tx port after every realignment of the Rx port.

For OC-3 and OC-12 the 16-bit wide internal bus is serialized to 155Mbps or 622 Mbps by the serializer 42. For OC-48 applications, theentire sixteen bit bus is output under the control of an externalserializer (not shown).

There is a potential for forty-eight different SPEs being generated forthe outgoing SONET interfaces. All of these SPEs may be generated from asingle timing reference. This allows all of the SPE generators to beshared among all of the SONET and Telecom bus interfaces withoutmultiplexing between the different clocks of the different SONET timingdomains. The SPE consists of the Path level overhead and the payloaddata. The payload data can be TDM, ATM or packet. All of these traffictypes are mapped into single SPEs or concatenated SPEs as desired bytheir respective standards. As the SPEs are generated, they aredeposited into SPE FIFOs. For each SPE there is a sixty-four-byte FIFOand these individual SPE FIFOs are concatenated through SPEconcatenation configuration registers. As described above, the fillstatus of the SPE FIFOs is used to determine the correct time to performa positive or negative pointer justification.

TDM, ATM and packet data may be all mapped into SONET SPEs as specifiedby their respective standards. The type of data carried in each of thepotential forty-eight SPEs may be configured through the external hostprocessor. Based on this configuration, each SPE generator may beallocated the correct type of mapper. All of this configuration may beperformed at initialization and may be changed when the particular SPEis first disabled. Once the configuration is complete, there may be anisolated set of functional blocks allocated to each SPE. This set offunctional blocks includes one of each of the following: payload mapper,payload FIFO, POH generator, SPE FIFO and SPE generator. Each of the ATMand packet payload mappers has a payload FIFO into which it writespayload data for a particular SPE. For TDM traffic, each potentialVirtual Container is allocated its own FIFO.

Returning now to FIG. 2, in each “datapath and link bandwidtharbitration module” 102, the data stream deserializer 126 synchronizesto the incoming serial data stream and then reassembles the row streamwhich is transported using two physical unilink channels. It alsoprovides FIFO buffering on each of the two incoming, serial streams sothat the streams may be “deskewed” prior to row reassembly. It recoversthe thirty-six-bit slot data from the row stream in a third FIFO whichis used for deskewing the twelve input links. This deskewing allows allthe input-links to forward slot N to the switching core simultaneously.The link deskewing is controlled by the link synchronization and timingcontrol module 150. The deserializer 126 also continuously monitors thedelta between where slot 0 of the incoming row is versus the internalrow boundary signal within the switch element. The difference may bereported to the Link RISC Processor 156 and used (in the first stage ofa switch) as part of the ranging process to synchronize the portprocessor connected to the input link.

The data-stream demapper 128 may be responsible for extracting the datafrom the incoming serial data links. It demaps the input link slotsbased on the input slot number and determines whether the traffic isTDM, PDU, or a request element (RE). For TDM traffic, the demapperdetermines the destination link and row buffer 132 memory address. Thisinformation is stored in a demapper RAM (not shown), which may beconfigured by software when TDM connections are added or torn down. ForPDU traffic, the demapper 128 assembles all sixteen slots which make upthe PDU into a single 64-byte PDU word, then forwards this entire PDUword to the row buffer mapper logic 130. The PDUs may be assembled priorto forwarding them to the row buffer 132 so that the row buffer mapper130 can write the entire PDU to the row buffer 132 in a single clockcycle. This provides the maximum possible write-side memory bandwidth tothe row buffer 132. It is a significant feature of the switch elementthat twelve entire PDUs are written to a single row buffer in six linkslot times (twelve core clock cycles). For request elements, thedemapper 128 assembles the three-slot block of REs into twoforty-eight-bit REs and forwards them to the request parser module 152.A detailed description of the data stream demapper 128 is provided inSections 4.3.1 et seq. of Appendix B.

The row buffer mapper 130 may be responsible for mapping traffic whichis received from the data stream demapper 128 into the row buffer 132.The mapper 130 provides FIFO buffers for the TDM traffic as it isreceived from the data stream demapper 128, then writes it to the rowbuffer 132. The row buffer memory address is actually preconfigured inthe demapper RAM (not shown) within the data stream demapper module 128.That module forwards the address to the row buffer mapper 130 along withthe TDM slot data. The mapper 130 also writes PDU traffic from the datastream demapper 128 to the row buffer 132 and computes the addresswithin the row buffer 132 where each PDU will be written. PDUs arewritten into the row buffers starting at address 0 and then everysixteen-slot address boundary thereafter, up to the maximum configurednumber of PDU addresses for the row buffer 132. A detailed descriptionof the row buffer mapper 130 is provided in Section 4.3.1.4 of AppendixB.

The row buffer 132 contains the row buffer memory elements. According tosome embodiments, it provides double buffered row storage which allowsone row buffer to be written during row N while the row data which waswritten during row N−1 is being read out by the data stream mapper 136.Each row buffer is capable of storing 1536 slots of data. This allowsthe row buffer to store ninety-six PDUs or 1536 TDM slots or acombination of the two traffic types. Request elements and link overheadslots may not be sent to the row buffer 132. Therefore the row buffermay not need to be sized to accommodate the entire 1700 input linkslots. According to some embodiments, the row buffer write port is16*36=576 bits wide and it supports writing of only one thirty-six-bitslot (TDM data) or writing of an entire 576-bit word (PDU data) in asingle clock cycle. A detailed description of the row buffer 132 isprovided in Section 4.3.1.4 of Appendix B.

Request arbitration utilizes two components: a centralized requestparser module 152 and a request arbitration module 134 for each of theoutput links. Request elements are extracted from the input slot streamby the data stream demapper 128 and are forwarded to the request parser152. The request parser 152 forwards the forty-eight-bit requestelements to the appropriate request arbitration module 134 via tworequest buses (part of the input link bus 120). Each request bus maycontain a new request element each core clock cycle. This timing allowsthe request arbitration logic to process thirteen request sources inless than eight core clock cycles. The thirteen request sources are thetwelve input data streams and the internal multicast and in band controlmessaging module 156. The request arbitration module 134 monitors thetwo request element buses and reads in all request elements which aretargeted for output links the request arbitration module isimplementing. According to some embodiments, the request arbitrationmodule 134 provides buffering for up to twenty-four request elements.When a new request element is received, it is stored in a free RE buffer(not shown). If there are not any free RE buffers, then the lowestpriority RE which is already stored in a buffer is replaced with the newRE if the new RE is a higher priority. If the new RE is equal to orlower in priority than all REs currently stored in the RE buffers thenthe new RE is discarded. On the output side, when the data stream mappermodule 138 is ready to receive the next RE, the request arbitrationmodule 134 forwards the highest priority RE which is stored in the REbuffers to the data stream mapper module 136. If the RE buffers areempty, then an “Idle” RE may be forwarded. A detailed description of therequest arbitration module 134 is provided in Section 7 of Appendix B.

The data stream mapper 136 may be responsible for inserting data andrequest elements into the outgoing serial data links. This includesmapping of the output link slots based on the output slot number todetermine if the traffic is TDM, PDU, request element, or test traffic.The determination is based on the contents of the mapper RAM (notshown). For TDM traffic, the row buffer memory address may be determinedfrom the mapper RAM which is configured by software as TDM connectionsare added or torn down. For PDU traffic, the data stream mapper 136 useone slot at a time from the row buffer 132. The row buffer memoryaddress may be stored in the mapper RAM by software. If the target PDUis not valid (i.e., a PDU was not written to that row buffer locationduring the previous row time), then the mapper 136 transmits an idlepattern in order to ensure that a data PDU is not duplicated within theswitch. For request elements, the mapper assembles the three-slot blockof REs-from two forty-eight-bit REs. The REs are read from—the requestarbitration module 134. For test patterns, the mapper 136 inserts theappropriate test pattern from the output link bus 122. These testpatterns are created by either the test pattern generator 162 or testinterface bus 164 modules.

The data stream mapper supports slot multicasting at the output stage.For example, the data stream mapper for any output link is able to copywhatever any other output link is sending out on the current slot time.This copying is controlled via the mapper RAM and allows the mapper tocopy the output data from another output link on a slot-by-slot basis. Adetailed description of the data stream mapper 136 is provided inSection 4 of Appendix B.

The data stream serializer 138 creates the output link serial stream.Data slots are received via the data stream mapper module 136 and thelink overhead is generated internally by the data stream serializer 138.The serializer 138 also splits the row data stream into two streams fortransmission on the two paths 110, 114. A detailed description of thismodule is provided in, Section 11 of Appendix B.

The grant stream deserializer 140 in each module 102 works in much thesame manner as the data stream deserializer 126. The primary differenceis that the grant data only utilizes a single path, thus eliminating theneed for deskewing and deinterleaving to recover a single input serialstream. Since this serial link is only one half the data stream rate ofthe forward link, there are 850 slots per row time. A single FIFO (notshown) may be used to allow for deskewing of the input serial grantstreams for all 12 links. A detailed description of the grant streamdeserializer 140 may be provided in Section 11 of Appendix B.

The grant stream demapper 142 may be responsible for extracting the datafrom the incoming serial grant links. This includes demapping of thereceived grant link slots based on the input slot number to determine ifthe traffic is a grant element or another kind of traffic. Thedetermination is based on the contents of the grant demapper RAM(not-shown). According to some embodiments, traffic other than grantelements is not yet defined. For grant elements, the grant streamdemapper 142 assembles the three-slot block of GEs into twoforty-eight-bit GEs and forwards them to the single grant parser module154. A detailed description of the grant stream demapper 142 is providedin Section 7.2.3.2 of Appendix B.

The grant arbitration module 144 operates in a similar manner to therequest arbitration logic 134. In some embodiments, this module isidentical to the request arbitration module. The only difference may bethat it processes grant elements in the reverse path instead of requestelements in the forward path. It will be recalled that grant elementsare, in fact, the request elements which have been returned.

The grant stream mapper 146 may be responsible for inserting data intothe outgoing serial grant links. It maps the output grant slots based onthe output slot number to determine if the traffic is a grant element ortest traffic. The determination is based on the contents of the grantmapper RAM (not shown). For grant elements, it assembles the three-slotblock of GEs from two forty-eight-bit GEs. The GEs are read from thegrant arbitration module 144. For test patterns, it inserts theappropriate test pattern from the output link bus 122. These testpatterns may be created by either the test pattern generator 162 or thetest interface bus 164 modules. A detailed description of the grantstream mapper 146 is provided in Section 7.2.3.2.

The grant stream serializer 148 works in much the same manner as thedata stream serializer 138. The primary difference is that the grantdata only utilizes a single path, thus eliminating the need forinterleaving the transmit serial stream across multiple output serialstreams. Since this serial link is only one half the forward data streamrate, there are only 850 slots per row time. A detailed description ofthe grant stream serializer 148 is provided in Section 11 of Appendix B.

The modules described above (except for the request parser and the grantparser) may be instantiated for each link module 102 of which there aretwelve for each switch element 100. The following modules may beinstantiated only once for each switch element.

The link synchronization & timing control 150 provides the globalsynchronization and timing signals used in the switch element. Itgenerates transmission control signals so that all serial outputs-startsending row data synchronized to the RSYNC (row synchronization) inputreference. It also controls the deskewing FIFOs in the data streamdeserializers so that all twelve input links will drive the data forslot N at the same time, onto the input link bus 120. This samedeskewing mechanism may be implemented on the grant streamdeserializers. A detailed description of the link synchronization andtiming control 150 is provided in Section 10 of Appendix B.

The request parser 152 receives inputs from all thirteen request elementsources and forwards the REs to the appropriate request arbitrationmodules via the two request element buses. A detailed description of therequest parser 152 is provided in Section 7.2.1.1 of Appendix B.

The grant parser 154 physically operates in a similar manner to and maybe identical to the request parser 152. The only difference is that itprocesses grant elements in the reverse path instead of request elementsin the forward path. As mentioned above, the grant elements contain thesame information as the request elements, i.e. the link address throughthe switch from one port processor to another.

The link RISC processor 156 controls the ranging synchronization on theinput links with the source port processors in the first stage of theswitch fabric. It also controls the ranging synchronization on theoutput link grant stream input with the source port processors in thelast stage of the switch fabric. It also handles the Req/Grantprocessing needed to transmit multicast messages and controls thereception and transmission of the in-band communications PDUs. Allin-band communications PDUs are forwarded to the Configuration RISCProcessor 158 which interprets the messages. The link RISC processor 156only handles the Req/Grant processing needed to transmit multicast andin-band communications messages.

The configuration RISC controller 158 processes configuration and statusmessages received from an external controller module (not shown) andin-band communication messages as described above. The system controlmodule 160 handles all the reset inputs and resets the appropriateinternal modules. The configuration RISC controller 158 and the systemcontrol module 160 may be implemented with an Xtensa™ processor fromTensilica, Inc., Santa Clara, Calif.

The test pattern generator and analyzer 162 may be used for thegeneration of various test patterns which can be sent out on any slot onthe data stream or grant stream outputs. It is also capable ofmonitoring input slots from either the received data stream or grantstream.

The test interface bus multiplexer 164 allows for sourcing transmit datafrom the external I/O pins and forwarding data to the I/O pins. This isused for testing the switch element when a port processor is notavailable.

The unilink PLL 166 may be used to create the IF clock needed by theunilink-macros. Within each unilink macro another PLL multiplies the IFclock up to the serial clock rate. The core PLL 168 may be used tocreate the clock used by the switch element core logic. In someembodiments, the core clock is approximately 250 MHz. A detaileddescription of both PLLs is provided in Section 9 of Appendix B.

The JTAG interface 170 may be used for two purposes: (1) boundary scantesting of the switch element at the ASIC fab and (2) Debug interfacefor the Configuration RISC Processor.

As shown in FIG. 2, there may be three datapath buses (the input linkbus 120, the output link bus 122, and the grant bus 124) which may beused to move switched traffic from the input links to the output-links.These buses are also used to carry traffic which is sourced orterminated internally within the switch element. Some datapaths of theinput link bus are summarized in Table 2 below. Some datapaths of theoutput link bus are summarized in Table 3 below. Some datapaths of thegrant bus are summarized in Table 4 below.

TABLE 2 Name Qty Width Description Source islot_num 1 11 Current inputslot number for Link Sync & Timing Ctrl traffic from the Data StreamDeserializers ilink_req_0 12 48 Request elements received on the DataStream Demapper thru input link module for each input link ilink_req_11lcl_req_0 1 48 Request elements generated locally Link RISC Controllerreq_a, req_b 2 48 Parsed request elements Request Parserilink_tdm_data_0 12 47 TDM data, 36-bit data + 11 bit Data StreamDemapper thru destination row buffer address module for each input link.ilink_req_11 ilink_tdm_dlink_0 12 4 Destination output link Data StreamDemapper thru (i.e., row buffer) identifier module for each input linkilink_tdm_dlink_11 ilink_pdu_0 12 512 Complete 64-byte PDU which hasbeen Data Stream Demapper thru assembled from the incoming slots modulefor each input link ilink_pdu_11 ilink_pdu_flag_0 12 13 Each flag isasserted for each destination Data Stream Demapper thru which thecurrent PDU is addressed. module for each input link ilink_pdu_flag_11Total destinations = 12 output links plus the internal MC and In-bandComm Controller lcl_pdu 1 64 Bus used to transport locally generatedPDUs Link RISC Controller to the Data Stream Demappers

TABLE 3 Name Qty Width Description Source oslot_num 1 11 Current outputslot number for Link Sync & Timing Ctrl traffic destined for the outputlinks. rbuf_dout_0 12 36 Slot data output from the row buffer. RowBuffer for each thru output link. rbuf_dout_11 rbuf_rd_addr 12 12 Rowbuffer read address. Data Stream Mapper for each output link. test_src1,3 36 Test traffic sources. Test Pattern Generator, test_src2, TestInterface Bus test_src3 idle_ptrn 1 36 Idle pattern which is transmittedData Stream Demapper when no valid PDU data is available. module foreach input link. olink_req_0 12 48 Request elements for each outputlink. Req Arbitration modules. thru olink_req_11 omap_data_0 12 36 Linkoutput after the mapping multiplexers. Data Stream Mapper for thru All12 outputs are fed back into each of each output link omap_data_11 theData Stream Mappers so that TDM multicasting can be done.

TABLE 4 Name Qty Width Description Source olink_gntslot_num 1 10 Currentinput slot number for traffic Link Sync & Timing Ctrl from the GrantStream Deserializers. olink_gnt_0 12 48 Grant elements received on thegrant Grant Stream Demapper. thru receiver which is associated witholink_gnt_11 the output link. olink_gntslot_0 12 36 Demapped slots fromthe received grant Grant Stream Demapper. thru stream. These are slotswhich are not olink_gndslot_11 carrying grant elements. gnt_a, gnt_b 248 Parsed grant elements Grant Parser

According to some embodiments, each switch element includes a multicastcontroller and a separate multicast PDU buffer. Multicast requestelements flow through the switch in the same manner as standard unicastrequest elements. At the point where the message needs to be multicast,the hop-by-hop field's bit code for that switch stage indicates that therequest is multicast. The request is forwarded to the multicastcontroller. On the grant path, the multicast controller sources a grantif there is room for the data in the multicast recirculating buffers.Once the data has been transmitted to the multicast buffer, themulticast controller examines the data header and determines whichoutput links it needs to be sent out on. At this point, the multicastcontroller sources a number of request messages which are handled in thesame manner as unicast requests.

There have been described and illustrated herein several embodiments ofa network switch which supports TDM, ATM, and IP traffic. Whileparticular embodiments of the invention have been described, it is notintended that the invention be limited thereto, as it is intended thatthe invention be as broad in scope as the art will allow and that thespecification be read likewise. It will therefore be appreciated bythose skilled in the art that yet other modifications could be made tothe provided invention without deviating from its spirit and scope as soclaimed.

1.-7. (canceled)
 8. A method comprising: transmitting a bandwidthrequest element; receiving a grant corresponding to the bandwidthrequest element; generating a protocol data unit (PDU) including routinginformation, to facilitate routing of the PDU through a plurality ofstages of a communication switch, and the PDU further including anindication of a first stage of the plurality of stages at whichmulticasting begins; and transmitting, based at least in part on saidreceiving of the grant, the PDU to the first stage.
 9. The methodaccording to claim 8, further comprising: copying the PDU at the firststage to produce one or more copies of the PDU; and replacing therouting information in the one or more copies of the PDU with updatedrouting information.
 10. The method according to claim 8, furthercomprising: transmitting the bandwidth request element in row N of adata frame; and transmitting the PDU in row N+1 of the data frame.
 11. Amethod comprising: generating a bandwidth request element includingrouting information, to facilitate routing of the bandwidth requestelement through a plurality of stages of a communication switch, and thebandwidth request element further including an indication of a firststage of the plurality of stages at which multicasting begins; andtransmitting the bandwidth request element to the first stage.
 12. Themethod according to claim 11, wherein the bandwidth request elementrequests bandwidth in row N+1 of a data frame and said method furthercomprises: transmitting the bandwidth request element in row N of thedata frame.
 13. The method according to claim 12, further comprising:transmitting the data frame in 125 microseconds.
 14. The methodaccording to claim 11, further comprising transmitting the bandwidthrequest element in an in-band link; and receiving a grant, correspondingto the bandwidth request element, via an out-of-band link.
 15. A systemcomprising: a receive switch controller configured to generate abandwidth request element including routing information, to facilitaterouting of the bandwidth request element through a plurality of stagesof a communication switch, and the bandwidth request element furtherincluding an indication of a first stage of the plurality of stages atwhich multicasting begins; and an interface coupled to the receiveswitch controller and configured to transmit the bandwidth requestelement to the first stage.
 16. The system according to claim 15,further comprising: a switch element acting as the first stage andincluding a controller configured to receive the bandwidth requestelement; copy the bandwidth request element to produce one or morecopies of the bandwidth request element; and replace the routinginformation in the one or more copies of the bandwidth request elementwith updated routing information.
 17. The system according to claim 15,wherein the interface is further configured to receive a grantcorresponding to the bandwidth request element.
 18. The system accordingto claim 15, wherein the receive switch controller comprises: a mapperconfigured to generate a repeating data frame including a plurality ofrows with the bandwidth request element in row N to request bandwidth inrow N+1.
 19. A system comprising: a receive switch controller togenerate a protocol data unit (PDU) including routing information, tofacilitate routing of the PDU through a plurality of stages of acommunication switch, and the PDU further including an indication of afirst stage of the plurality of stages at which multicasting begins; andan interface coupled to the receive switch controller and configured totransmit a bandwidth request element, to receive a grant correspondingto the bandwidth request element, and to transmit the PDU to the firststage based at least in part on said receiving of the grant.
 20. Thesystem according to claim 19, further comprising: a switch elementacting as the first stage and including a controller configured toreceive the PDU; copy the PDU to produce one or more copies of the PDU;and replace the routing information in the one or more copies of the PDUwith updated routing information.
 21. The system according to claim 19,wherein the receive switch controller comprises: a mapper to generate arepeating data frame including a plurality of rows with the bandwidthrequest element in row N to request bandwidth in row N+1.
 22. Acommunications switch comprising: a first switch element including oneor more ports; a second switch element including one or more ports; anda port processor including a first switch element interface coupled to afirst port of the one or more ports of the first switch element; asecond switch element interface coupled to a first port of the one ormore ports of the second switch element; and a receive switch controllerconfigured to automatically redirect traffic to either of said first orsecond switch element interfaces based at least in part on a switchcongestion event.
 23. The communications switch according to claim 22,wherein the first port of the first switch element and the first port ofthe second switch element each comprise a plurality of interleavedserial links.
 24. The communications switch according to claim 22,wherein the receive switch controller is configured to automaticallyredirect traffic to either of said first or second switch elementinterfaces based at least in part on a switch failure.
 25. Acommunications switch comprising: a switch element including a firstport and a second port; and a port processor including a first switchelement interface coupled to the first port; a second switch elementinterface coupled to the second port; and a receive switch controllerconfigured to automatically redirect traffic to either of said first orsecond switch element interfaces based at least in part on a switchfailure or congestion event.
 26. The communications switch according toclaim 25, wherein each of said first and second ports comprise aplurality of interleaved serial links.
 27. A communications switchcomprising: a first switch fabric including a plurality of first switchelements; a second switch fabric including a plurality of second switchelements; and a port processor including a first switch fabric interfacecoupled to one of the plurality of first switch elements, a secondswitch fabric interface coupled to one of the plurality of second switchelements, and a receive switch controller configured to automaticallyredirecting network traffic through either of said first switch fabricor said second switch fabric based at least in part on switchcongestion.
 28. The communications switch according to claim 27, whereinthe receive switch controller is further configured to automaticallyredirect network traffic through either of said first switch fabric orsaid second switch fabric based at least in part on switch failure. 29.A communications switch comprising: a plurality of switch elements; anda port processor configured to repeatedly transmit a request elementthrough a first subset of the plurality of switch elements based atleast in part on a first routing tag in the request element until agrant corresponding to the request is received or the request istransmitted through the first subset a predetermined number of times,and, in an event in which the request is transmitted through the firstsubset a predetermined number of times, to transmit the request elementthrough a second subset of the plurality of switch elements based atleast in part on a second routing tag in the request element.
 30. Thecommunication switch of claim 29, wherein the request element includes achannel tag and the system further comprises: a first switch fabricincluding the plurality of switch elements; a second switch fabric; andthe port processor is further configured to transmit the request elementover the first switch fabric or the second switch fabric based at leastin part on the channel tag.